The occurrence of a hardware, software, network, process, or system failures in a database system could result in corruption, inconsistencies, or errors to database data. To prevent such problems from occurring, many database systems implement recovery mechanisms capable of restoring the database to a consistent and error-free state if such failures are detected. Recovery mechanisms typically utilize one or more recovery logs or recovery files (collectively referred to herein as “recovery logs”) to perform the recovery process. Recovery logs record information about the database data, such as changes to the database data or the state of database data as of a certain point in time.
A commonly implemented recovery log is a “redo log” or “redo stream”. Redo streams contain records of all changes made to objects in a database system, regardless of whether the changes are committed or uncommitted. For example, the redo log may record a stream of data containing the identity of each data item that changed in the database, as well as the precise change that is made to the data item. If a failure occurs, the redo stream can be used during the recovery process to “redo” any changes that occurred prior to the failure, to place the database in a consistent state as of a specific point in time.
Since recovery logs, such as redo logs or streams, effectively become a historical repository for all changes made to the database data, the information recorded in the recovery logs can be used for many purposes beyond just system recovery operations. For example, the redo stream information may be used to drive asynchronous applications that provide a variety of functionality, such as:
Logical Standby where a standby database shadows a primary database by extracting committed transactions out of the redo stream and applying them;
Log Based replication where a replica site extracts committed changes made to the tables of interest and applies them to keep the replica tables synchronized; and
Log Analysis whereby a user issues Structured Query Language (SQL) queries against a fixed view to determine changes applied to the database.
For example, the redo stream may be analyzed by processing each record in the redo stream to reconstruct the equivalent Data Manipulation Language (DML) statement. DMLs belonging to the same transaction are grouped together and committed transactions are returned to the application.
However, since redo records only identify the modified schema objects (or the associated columns) by internally generated numbers, log analysis and subsequent application of transactions generate output that is not easily readable by a person. In order to produce output that is more easily readable by a person, a data dictionary may be used to provide the mapping between the numbers and the corresponding user defined names. For example, Structured Query Language (SQL) statements use column names and table names that typically have meaning to a person, while the internal database schema identifies the corresponding columns and tables with internally generated numbers.
Thus, the need arises to generate and utilize a data dictionary to provide the mapping between the internal numbers and the corresponding user defined names so that applications that utilize the redo stream can generate output that is more easily readable by a person. One conventional technique saved the data dictionary information in a file that was separate from the redo stream. Use of this data dictionary then required the entries in the data dictionary to be temporally matched with the entries in the redo stream, which was a difficult and time-consuming process.
The need arises for a technique by which information needed to provide data dictionary information of database objects relating to the association between the internal numbers used by a database schema to identify database objects and the corresponding user-defined names of the database objects may be generated so that the association information may be easily and quickly used in the analysis of a redo stream of the database transactions.